This is definitely going in the right direction, but I have a few comments.

I think it's better to have many small actions that tell you one specific thing that's wrong with your PR rather than a mega action that could fail for many reasons and you have to go digging in logs every time.

For example, cargo fmt --all -- --check is already covered by @npajkovsky 's:

https://github.com/bcgit/bc-rust/blob/release/0.1.2alpha/.github/workflows/rust-style.yml

Similarly, I would split out cargo clippy into a separate action. Also, cargo clippy is currently throwing hundreds of errors and warnings, so I think we first need a github issue to get the codebase to a clean state before we can start complaining about this on PRs.

This is definitely going in the right direction, but I have a few comments.

I think it's better to have many small actions that tell you one specific thing that's wrong with your PR rather than a mega action that could fail for many reasons and you have to go digging in logs every time.

For example, cargo fmt --all -- --check is already covered by @npajkovsky 's:

https://github.com/bcgit/bc-rust/blob/release/0.1.2alpha/.github/workflows/rust-style.yml

Similarly, I would split out cargo clippy into a separate action. Also, cargo clippy is currently throwing hundreds of errors and warnings, so I think we first need a github issue to get the codebase to a clean state before we can start complaining about this on PRs.

@ounsworth ACK. Will split into several smaller Github actions and branches wildcarded into release/*

Can you also make a docsLlint action that runs

cargo doc --all

?

It would also be cool to put the github CI badges on the main readme.

@ounsworth rebased off of bcgit release/0.1.3alpha, added in badges into the README.md, and split up CI actions into different yml files

Note about rustfmt failing: I verified that the rustfmt failures are in files not modified by this PR and are already present on release/0.1.3alpha. Since cargo fmt --all -- --check checks the entire workspace, the existing formatting debt causes this PR to fail despite not introducing those changes.

Repository-wide formatting cleanup should be handled separately, not in this PR.

Hey @officialfrancismendoza, I'm taking a look here to help get this PR moving along - looks good overall! Just a couple quick things:

1. I see that actions/checkout@v4 is being used - is there a particular reason to use v4? I see there are newer releases available
2. I've tried manually viewing the badge SVGs in my browser (e.g., https://github.com/bcgit/bc-rust/actions/workflows/rust-style.yml/badge.svg), but they load with the text saying "no status" - any idea why they might not be working?
3. Rust Style failing - your reasoning makes sense if it's unrelated to this PR

I'm a bit new to github actions, so I hope those questions make sense!

Hey @officialfrancismendoza, I'm taking a look here to help get this PR moving along - looks good overall! Just a couple quick things:

1. I see that actions/checkout@v4 is being used - is there a particular reason to use v4? I see there are newer releases available
2. I've tried manually viewing the badge SVGs in my browser (e.g., https://github.com/bcgit/bc-rust/actions/workflows/rust-style.yml/badge.svg), but they load with the text saying "no status" - any idea why they might not be working?
3. Rust Style failing - your reasoning makes sense if it's unrelated to this PR

I'm a bit new to github actions, so I hope those questions make sense!

@jjkurczak there wasn't a particular workflow-related reason; v4 was the version I used as the established stable release. I’m happy to update it to the repository’s preferred version if we want to standardize on a newer major. I didn't change versions since the major releases include behavioral changes.

As for why the badges don't show status, they default to the repository's default branch. The README badge points to canonical bcgit/bc-rust and not the fork. The workflow files only exist in this feature branch until it's merged. So until the workflow is merged into bcgit/bc-rust (and reflected downstream here, on the public github repo that mirrors from the authoritative source), it will report "no status".

We could also scope the badge URLs to feature branches going forward or add push triggers for release/* if you want the badges to represent the current health of release branches rather than PR runs, but that's up to Mike.

Hey @officialfrancismendoza, I'm taking a look here to help get this PR moving along - looks good overall! Just a couple quick things:

1. I see that actions/checkout@v4 is being used - is there a particular reason to use v4? I see there are newer releases available
2. I've tried manually viewing the badge SVGs in my browser (e.g., https://github.com/bcgit/bc-rust/actions/workflows/rust-style.yml/badge.svg), but they load with the text saying "no status" - any idea why they might not be working?
3. Rust Style failing - your reasoning makes sense if it's unrelated to this PR

I'm a bit new to github actions, so I hope those questions make sense!

@jjkurczak thanks for the review! There wasn't a particular workflow-related reason; v4 was the version I used as the established stable release. I’m happy to update it to the repository’s preferred version if we want to standardize on a newer version.

As for why the badges don't show status, they default to the repository's default branch. The README badge points to canonical bcgit/bc-rust and not the fork. The workflow files only exist in this feature branch until it's merged. So until the workflow is merged into bcgit/bc-rust (and reflected downstream here, on the public github repo that mirrors from the authoritative source), it will report "no status".

We could also scope the badge URLs to feature branches going forward or add push triggers for release/* if you want the badges to represent the current health of release branches rather than PR runs, but that's up to Mike.